This is my TO DO list...things that I want to do for the shell in future releases. Of couse, some things that need to be done are left off here (like fixing bugs, general improvement of the code, etc.). If you are feeling adventurous, try to impliment some of this stuff into HAS; if you do, lemme know and see the code so I can try to officially integrate it into HAS.
Oh, anything with "NOW" in front of it I want to get done relatively soon. Anything with "future" in front of it is total blue sky stuff. And stuff with "DONE" in front of it was something I wanted to do and got done (like a checklist).
NOW: in every place that i check for a playing sound (as if to stop it), i need
to also check for speaking and stop that too. Perhaps write a function like
SoundIsPlaying like a HsoiIsSpeaking() function to check for spekaing, and maybe
also another HsoiIsSoundPlaying() to check for any sounds or speech. And
then i think HsoiDoStop works fine to stop both sound and/or speech
DONE: of course, write the README, the general overview and setup and usage and
philosophy of the shell, URL list, legal info, distribution contents (y'know,
i wonder....tho i doubt it'd work...if i embedded HFS objects to the various
related files, would i be able to distribute them this way.
e.g. in the README when i say "Refer to the document 'HAS Legal Info' for
more information" if i put a HFS object to the HAS Legal Info document in
there, would the alias remain intact and work on someone elses computer?
i doubt it, but it might be worth a try! if so, it's be like a crude
hypertext link.
NOW: I'll need to update the help text (and possibly trim it down of old crap)
DONE: get the sound menu and text-to-speech menu working
one thing in that list will be: general improvement and brushing up of
code, adding more features, fixing bugs, listening to and responding
to user requests and questions and stuff, writing a better error handling
routine(s) and making them more robust and thorough in the code even if
i have to totally scrap my existing error handling.
future: impliment a parsing for the text files to be able to go between
SimpleText files and HAS (read in/write out either format)...this is
like for PICTs and snds and other embedded objects.
future: a way to deal with non-Macintosh files, like able to parse and/or
strip funny characters like line feeds, etc (start with what Tex-Edit+ does)
future: in the custom putfile proceedure, allow to save as a editable
document or a read-only (again with the HAS/SimpleText stuff)
future: allow supported data (PICTs, snds) to be handled better.
like allow a PICT file on the desktop to be dragged to and read into
a file (perhaps just create as a regualr document and then insert it
as SOUP or something). same for clipping files.
future: if a file contained only some SOUP, like just a PICT or
just a snd, to be saved as such also...sorta like how SimpleText does
future: get Marco's movable modal library working (man, this bothers me)
future: continue with Copland support
future: fix known bugs: about box on PPC's, text prefs popup menu problem,
why some HFS drags crash/hang
future: redo prefs code with that icon pane thing
future: the SlimApp trimming of 68k/PPC code from fat binaries at runtime
NOW: get some sort of beter MacOS way of getting floating numbers from dialogs.
use the StringToExtended stuff
future: some sort of Find code to give the modeless dialog a purpose
future: having document specific settings for the printer...in fact,
a possible total rewrite of the printing code, especially as to why
the damn cancelation won't work..maybe also buff up the idle proc dlg
box (show pages printing...check to make sure this would work right
for odd pages, like 5 to 8 and for multiple copies)
future: readjust the window after a change in the Page Setup dialog
future: support GX printing
future: print apple event
future: saving window locations (like the find dialog or something) but
do do something to make sure that if the window would appear offscreen
that it gets drawn in a default position. also, what about multisync
monitors? like in the office? if they switched to a lower resolution,
how does the MacOS deal with what would then be an offscreen window?
perhaps the Display Manager?
future: unique margin settings for each document...goes along with the
unique printer settings for each document. also have a global margin
settings for "new" documents or docs w/o the setings or whatever
(this will be important to check for....)
•• OH...ok..on the note of saving margin settings and in fact, saving
anything...when we save a document, make sure to not save more than
is necessary. for example, for HAS documents, just save whatever.
but like for SimpleText documents, that wouldn't save printer settings
(maybe save them in the document's docrec while it's open, but don't
write them to the file). but also, if it's a straight text file,
like say a CW IDE document, don't save stuff like 'styl' and stuff.
hrm...like if we saved a CW IDE document as then a HAS file, of course
save all the data, but hrm...this'll be fun to impliment...
future: instead of using Fred Flinstone and stuff like that in the
registration dialog, try to get them from the System file as per
the Sharing Setup control panel or via Internet Config!
future: a "factory settings" and/or a "revert" button in the prefs
dialog(s). and maybe also a "save now" button.
NOW: make sure to check for WASTE preprocessor conditional macros
in the code. for instance, if we're not using SOUP/embedded-objects,
we probably don't need to deal with a lot of things, like writing
SOUP out to files, reading it in, ability to play sounds, etc. also,
check about the WENew mono-style flag....if it's set, from how
the WASTE API looks, we don't use style nor soup...but check into
this.
future: balloon help
future: Edition Manager support
future: flip through any and all sample code i have and can find and see
what other sorts of things might be nice to add or (re)write to add
more funcationality or whatever.
future: an insert file menu command. gives the standard GetFile dialog,
but when the file is "opened," we check it's type. if it's a type of
file not supported by HAS, insert an HFS object. if it's a type supported,
give a dialog asking the user to cancel it all, open and read in the file
inserting it at the insertion point, or make an HFS object for it. it
probably should be a CustomGetFile dialog with 2 buttons...the standard
open button, but also an "add" button in case the user wants to insert a
file that normally would not be able to be selected in a GetFile (like
a folder or disk).
future: more keyboard cmd-key equivs...
future: on that above note, look into the Mercutio MDEF and the Infinity WDEF
future: other xDEFs (CDEFs, LDEFs and stuff like that)
future: support stationary files (one's that sit and don't go anywhere) ;)
future: finish writing all the code that's half-finished.
